FAQ AmigaOne

Most new minor information concerning the AmigaOne has been released on the mailing list rather than on this FAQ. Hence what follows is excerpts containing factual information taken from the mailing list.

> This is the same problem with the Zorro slots for the AmigaOne 4000.
> A large part of the present Amiga park is equipped with some boards
> which don't have their equivalent in PCI.
>
> [snip]
>
> The Amiga market is so small that we cannot allow ourselves to lose
> any potential buyers, and these people cannot lose all the work they
> have been doing for many years.

Ultimately the AmigaOne is a transitionary product designed to run the Amiga
DE and its applications in stand alone mode, and either fully retargetable
Amiga applications - or those which rely on the AA chipset - in the
meantime. It is not designed to run Classic Amiga applications that rely on
specific Zorro hardware. If this is your requirement then your only
(guaranteed) option is to keep running your existing hardware (possibly
networked to the A1) at present, and ultimately replace it with functionally
equivalent (ie better) PCI hardware and associated software running under
the Amiga DE.


> In fact, as an Amiga dealer we know that about 50%
> of our customers have a SCSI configuration.
> We do not want to lose this market and we are sure you do not want too.
> It's not the time to do again the same mistakes done in the past !
> Many A3000 users didn't buy the A4000 one when it was released
> just because of the SCSI and the flicker-fixer.
> You can't tell a third party will be able to write the driver.
> You must reassure the Amiga cummunity and tell them
> that a SCSI solution will be ready when the AmigaOne will be launched.

The AmigaOne 1200/4000 have been developed to the Zico spec laid down by
Amiga Inc. This does not include SCSI or Zorro.
However we fully expect SCSI drivers to be written/ported by third parties
for one or more specific cards shortly after the board starts shipping.

As far as Zorro compatibility is concerned the layout of the A1 main board
is extremely critical because of the high speed of the bus etc.
This causes a real problem in trying to route the 200 signal lines from the
A4000's CPU slot to the Westbridge interface VLGA chip through the A4000's
Zorro riser and potential Toaster compatible Zorro3/video slot (which uses a
through hole connector and therefore uses space on all pcb layers). We're
still looking to see if this can be solved reliably, and thats one of the
reasons that the (simpler) AmigaOne 1200 is coming out first.

If it can be done however it will add significantly to the cost of the
AmigaOne-4000 because of extra PCB real estate and additional production
costs.


> Do you plan to include in the flashrom some VESA drivers so that we can see
> the Early Startup Menu or the "BIOS setup" of the A1 on a SVGA screen ?

yes this is the intention - but it will be implemented by third parties, so
exactly how its implemented will be down to them.


> I understand that the AmigaOne motherboard is going to use SDRAM PC100.
>
> How many slots will it have and what is going to be the maximum amount of
> RAM that can it address?

2 x SDRAM slots

1GB of SDRAM address space has been allocated


> So I was thinking that it may be possible to mount the AmigaOne in an
> external case to the classic Amiga and then connect the CPU slot on the
> classic Amiga to the AmigaOne's connector via a short cable? Or would
> signal timing and synchronization issues prevent this from being a
> workable solution?

This is the whole issue. The whole board layout has to be optimised to work
at these speeds, including trace length equalisation etc etc. Cables of any
sort are certainly a no-no.

Although the A4000 & A1200 versions share much of the same internal logic
they are completely different board layouts, needing separate testing,
production setup etc. The additional development costs per new board layout
through to being 'production-ready' approach USD 6 digits (without our
apportioned overheads) so we have to be very sure of future sales potential
before embarking on an AmigaOne 3000 design. And that still doesn't solve
the Zorro issue, as previously discussed.

Perhaps a better approach might be to buy a complete A1200/AmigaOne/Z4Tower
and network it to your A3000. That would almost certainly come in
significantly cheaper than an AmigaOne 3000.


> I hope the flashrom implementation will be "secured" in some way, such as
> write access being dependant on something physical, like a shorted serial
> port lead (to stop virii writing themselves to the "bios")

This has already been covered in this list. Yes the Flashrom will be
write-protectable.


> PS: with the AmigaOne / hardware interface for backwards compatibility,
> would it be possible to speed up the emulation layer by copying the roms for
> instance, to file on the AmiOne filesystem

Its much faster to copy the ROMs to RAM, than to copy an HD image of the
ROMs to RAM.


> I was obviously not the only one who thought only a single DIMM was
> required.

You only need 1 SDRAM DIMM, and if you use 2 they can be of different sizes.


> When I get my mits on the new Amiga One-1200 I'll be using it in a
> Eyetech-Z4 tower with an original A1200 to start with.
>
> How do I power them both from the same internal PSU? Sorry if this
> has an obvious answer, but I'm a thicky...

The EZ-Tower Z4 has an ATX power supply in, and the AmigaOne has an ATX PSU
connector on it. You will be able to connect these two - and voila - power
:-)

Power to the A1200 motherboard can pass through the A1200 expansion
connector - as the amount required by it will be minimal. If extra power is
required (perhaps because of a lot of classic peripherals on the A1200 m/b),
then power can be applied to the A1200 floppy drive power connector.


> All well and good for the dealers/system builders but what about us
> normal non-dealer type people??

You buy from dealers (including, if you wish, Eyetech's retail division)
just as you do with any other piece of Amiga or PC computer hardware.


> I've got a suggestion though. Given that there is a lot of interest in
> the Linux world for non-Apple PPC systems, would it be worth while to also
> consider putting together AmigaONE systems that would include a Linux
> distribution (Mandrake is my favorite) along with the Linux AmigaDE SDK?
> That would give you guys a very open market, particularly once the
> application builder is finished (next DESDK release?).

First things first.

Our main (and only current) objective is to produce the first new Amiga in
10 years for the amiga community, running the Amiga operating system
specified/developed by Amiga inc.

Whilst Amiga Inc are getting all the details of OS4/5 up on their own
website I thought it might be useful to give my own views as to where we
are, where we are going and why the St Louis announcement was so pivotal to
the future of the Amiga. Its quite long I'm afraid, but hopefully a useful
basis for further discussion. If the general consensus is that it helps
clarify the issues involved I'll also stick it in the AmigaOne section of
our web site. If I've got some details wrong I'm sure Fleecy will comment
;-)

Over the last few months we have been working closely with Amiga Inc to
ensure that the AmigaOne is worthy of being the next generation Amiga - and
that of course means that it must have a robust, expandable, secure,
efficient real time operating system. But that was meant to be the Amiga DE
wasn't it? Well yes and no. The Amiga DE is a quite basic real-time
operating system designed primarily for single tasking - and certainly
single user - operations on embedded systems such as set top boxes, PDA's,
cell phones etc. And since these devices have both low power cpu's and very
limited user interfaces the DE needs to be free of much of the clutter that
we normally take for granted in a desktop operating system.

On the other hand a home server - the central box that coordinates all the
Amiga DE devices and runs 'proper' desktop applications - needs many more
facilities, such as task-level memory protection and OS-level virtual
memory, that are not practical to implement within the DE without completely
compromising its portability and speed.

So what we have now ended up with is the best of both worlds. Desktop Amiga
users will have a desktop/server OS, natively coded for the PPC, with added
memory protection, virtual memory and a much improved file system, whilst
still retaining the efficiency, real time responsiveness, elegance and
familiarity of the Classic Amiga OS. The DE will follow its own development
path but be totally integrated within OS4+

Developing the new OS is to be a 4-stage process:

- OS4.0 will be an updated version of OS3.9 with special facilities added to
allow existing classic Amiga applications to run on the AmigaOne, accessing
the classic Amiga hardware via the hardware bridge on the AmigaOne
1200/4000. Much of the operating system will still be in 680x0 code with in
line instruction conversion to PPC code.

- OS4.2 will add additional features and the recoding of much of the OS in
native PPC code. However the major milestone in this release will be the
complete retargeting of all operating system I/O away from Amiga specific
hardware/chipsets. This means that retargetable 'Classic' applications can
be run on the AmigaOne (or any Zico-compliant PPC board) without any
'classic' Amiga hardware present. At this stage the Amiga DE will also be
ported to the Amiga OS so that the AmigaOne can be used as a
development/porting platform for Amiga DE content (as a more familiar
alternative to the currently available Windows/Linux development
environments). Drivers will obviously be provided for those resources which
are retargeted to the AmigaOne motherboard (USB, sound, graphics, UDMA etc).

- OS4.5 will be an entirely PPC-native, entirely hardware independant
version of the operating system, with full driver support for all Zico
resources (FireWire, Matrox NG graphics cards, SCSI etc)

- OS5 is a full 64-bit fully distributed AMP operating system which will
implement virtual memory, memory protection and the Amiga DE in a
fully-spec'd, modular home-server/desktop OS.

OS4.x will only run on PPC boards conforming to the Zico specifications
which excludes BlizzardPPC & CyberStormPPC accelerators - even when coupled
with a Predator-SE PCI bus. We (and Amiga Inc) are pressing DCE, the current
manufacturers of these boards, to come up with a 'Zico compliance kit' to
preserve the investment of existing BPPC/CSPPC users and allow them to run
OS4.x.

Of course this means that - from OS 4.2 on - you will only need a existing
'Classic' Amiga for those few applications that are genuinely not
retargetable (ie those that still insist on 'hitting' the classic hardware).
All of the existing application software developers we have spoken to are
more than willing to port their applications to a fully hardware independent
PPC AmigaOne. This also means that by the time we would have scheduled the
design and production of the AmigaOne 3000 it would probably be an
irrelevant piece of hardware as far as most users are concerned. We're not
closing that door just yet, but, because of this hardware independance from
OS4.2 onwards we believe that existing Ax000 users will be able to run their
applications on stand-alone AmigaOne PPC hardware much sooner than we had
originally anticipated. And as far as that most famous of all big-box Amiga
accessories is concerned - the Video Toaster - we are going straight round
to NewTek ask them to port drivers for their existing PCI-based Toaster to
OS4.x as soon as production AmigaOnes are released!

Finally, one of the most significant parts of the announcement is that Amiga
Inc have decided - quite properly in my view - to take their ownership of
the Amiga OS seriously. They are taking development control, standards
definition and quality assurance for the Amiga OS back in house for the
first time since 1984. This is the first step in ensuring that we are no
longer blighted with compatibility issues between different software
modules, or 'kernel wars' between third party developers. Provided everyone
is sufficiently unbiassed to see the move in this light there is no reason
why Amiga shouldn't choose the best elements from Haage & Partner's WarpOS,
Ralph Schmidts's MorphOS, the work from the AROS project team and the
existing Classic OS in developing OS4 & 5. The important thing is that we
now have - in the shape of Fleecy Moss - a combined helmsman, navigator and
Captain for the Amiga OS. And I for one am fully committing our AmigaOne
hardware to Amiga's new OS strategy - for the sake of forward compatibility
and reliability - and without the diversion of seeing if we can get Linux,
MorphOS or anything else running on the AmigaOne board.


> I have been looking at the pics on the Eyetech site and have noticed the
> following pieces missing from the board......
>
> 1. Keyboard socket
> 2. Floppy interface
> 3. Serial port
> 4. Paralell Port

All via USB as per the Zico specs. USB adapters for these things are readily
available & cheap if you dont want to use a direct USB accessory.


> I think that the addition of an A1200 motherboard may cure these problems
> (apart from the keyboard probably), but what if you are going to use the
> A-One board as standalone?

You can of course continue to use the A1200 I/O up to OS5 - the
retargetability includes being able to retarget back to the original A1200
I/O.


> The problem is the non-retargetable programs. Having used a Draco, I
> know that this is a major practical problem. There are still many
> essential programs which run (legally) on AGA, as that is the official
> requirement for a legal Amiga program. Most of the companies concerned
> are out of the Amiga market, and generally have lost the source code.
>
> Scala is an obvious example. ProDraw, Brilliance, ImageMaster, DPaint,
> etc are all still useful.
>
> And won't people want to play classic games?

Yes - and they have 2 choices - keep the original Amiga connected to the
AmigaOne, or remove it and us it on its own for those odd, (sad?) retro
moments.

What the AmigaOne 1200/4000 gives is a modern computer and operating system
and 18-24 months breathing space of full compatibility (before OS5)


> The point is that some subset of UAE needs to be built into the RTG
> system, to emulate AGA on the new graphics cards. The alternative, of
> course, is the hardware emulation that is supposed to be in the BoXeR -
> but that may never happen.

My understanding is that this dioes not form part of AI's plans and I
wouldn't want to ask them to do anything else that pushed back thier
timescales. I agree that a UAE-type solution might be the best option for
compatibility with old low resource - demanding games for people without
'classic amiga' hardware attached, but I would swee this as just another
application running on top of OS4/5 - like Amiga Forever does on Windows.
I'm sure someone will want to port it, and at least we will have decent
hardware resources and a fast, documented, realtime OS to provide the
support functions.


>> Of course this means that - from OS 4.2 on - you will only need a
>> existing 'Classic' Amiga for those few applications that are genuinely
>> not retargetable (ie those that still insist on 'hitting' the classic
>> hardware).
>
> Will the later versions still support the A1200 motherboard for this?

Up to OS5 the original Amiga hardware, if attached, will form part of the
retargetable resources targets.


> If I read this right, this means that PCI cards will not be working in
> OS4.0, so you won't be able to retarget graphics and sound to the
> newer hardware?

No, that is incorrect. OS4.0 will support current PCI cards which are
available through existing API's


> How about we have a "Boing" key & an "Amiga" key instead,
> for any new keyboard standards, with suitable stickers supplied.....

If we can standardize on a particular model of PC k/b we can easily and
cheaply have special keycaps engraved/printed.


> What is the entry level CPU for the amigaOne

It will be down to the individual dealer as to which cpu models/speeds he
stocks but wit the Mac zif 233 G3 0.5MB backside cache being available for
about USD30 that realistically will be the entry level


> Will this EZKey-XS adapter be (optionally) bundled with the AmigaOne?

This is a product that is and will continue to be made available to other
dealers. Bundling is not appropriate as many A1 purchasers will already have
suitable towers and keyboard adapters from us, elbox and/or our respective
dealers.


> And now for the old question:
>
> In a previous message you mentioned an "xMON" switcher for SD/FF usage.
> Will this xMON switcher be offered as an option at purchase time?

Bundling/availability - same as above. The xMON takes video output from any
internal scan doubler (optionally with flicker fixer) and from the 15pin
SVGA connector of the graphics card in response to a control signal. Ideally
the control signal should be issued by the RTG driver when it switches the
current display between AGA & graphics card. (The CV64-3D card provides such
a switching signal for example). Alternatively it can be switched via
hardware on the k/b adapter in response to a particular key combination
(Amiga-Amiga-up arrow in the case of the EZKey-XS - see the docs on our web
site www.eyetech.co.uk for more info) - or even by a front panel switch.

Since this feature will only be needed when an actual A1200 is attached it
does not really make sense to build in the extra hardware latches etc needed
onto the A1 mobo as that then increases costs for everyone whether they need
it or not. However it is perfectly feasible that the RTG driver could
trigger a pin on the A1200 mobo that is unlikely to be used in its A1-1200
configuration - eg on the external floppy connector - to provide automatic
switching.


> And which kinds of ScanDoublers/FlickerFixers does it support?

All actually, but internal ones make the cabling easier.

the 'x' in xMON/y refers to the graphics card connection and the y refers to
the AGA-side connection

x=S -> SVGA (15p) gfx card
x=B -> B/CvPPC gfx card
x=A -> CV64-3D (autoswitching)

y=F -> internal DCE-style SD &/or FF
y=V-> VGA (15p) SD/FF connector (external SD/FF)
y=A-> Amiga 23p RGB connector


> I am still interested in anybody's comments on my previous post,
> especially about what will happen to classic hardware and software
> compatibility in OS 4.2+. Even though 4.2 allows "all applications
> to be able to operate without the need for physically attached older
> Amiga hardware", that doesn't imply to me that we'd be _forced_ to
> give up anything.

This is not quite correct. By 4.2 all OS functions will be hardware
independant (ie the can use hardware resources provided either by an
attached classic Amiga or the A1 board) but programs that have been written
to hit the classic hardware direct - eg Scala MM400 - will still require an
A1200 to be present to provide those hardware resources. 'OS legal' classic
programs shoud run fine without an attached A1200.


> Under OS5, I see Amiga implementing the more
> cutting-edge ideas they originally talked about when bringing AmigaDE
> to the desktop, and we might infer that classic compatibility would
> stop here...

Its meant to run OS4 (and therefore retargetable Classic apps) in a
'sandbox' (or should that be sandpit???)


> have you decided to definitely build the AmigaOne-4000

Our first priority is to get the A1-1200 in production, and we are about 1
week behind target with that (but still within the delivery timeframes of
OS4.0 - so no end user slippage).

Once that is done we will cost out the design/production of the A1-4000, and
estimate the time to ship. However this is likely to be in the same
timeframe as the release of hardware independant OS4.2 (which was never on
the cards when we first announced the A1-1200/4000). That means all hardware
retargetable applications will (should!) run without an attached Classic
Amiga. That in turn means that we would be only building the A1-4000 for
those that had applications that were impossible to retarget - ie an even
smaller target market.

For these applications, many will be superceded with ppc/A1- native
applications (eg video editing etc using firewire) whilst others will not
really gain anything from moving them to an A1-4000 platform (there is no
benefit as far as I can see for running a video toaster at 600fps!). For
these applications perhaps the most sensible solution is to keep the A4k as
it is with a high-speed network link to a standalone A1 where all the
processor intensive work can be carried out. If this is realistic then the
target market for the A1-4000 shrinks again.

Below a certain point the level of sales means that the A1-4000 becomes
economically unviable to develop and manufacture, and that is the
caclulation we need to do after we have re-assessed the
development/production costs. If the numbers stack up we'll do it; if they
don't we won't.


> "While I can accept that my Mk.4 Eyetech EZTower is going
> to have to be replaced if I want to enjoy the AmigaOne 1200 in
> a few months time, I find myself rather frustrated by the
> alternatives.

If yo want to continue to use the Mk4 EZtower you can mount the A1-1200 in
the AT/ATX side of the tower and network it internally to your existing
A1200. Obviously the A1-1200 doesnt have direct access to the AA chipset in
this configuration so you'll have to wait for OS4.2. Then run retargetable
applications on the A1 and non retargetable apps on the original A1200,
sharing storage, keyboard, screen etc.


> Show me an official statement (i.e. a posting, web page, IRC log)
> where an Amiga, H&P or Eyetech employee states that AOS 4.0 won't run
> existing WarpOS software. You won't find any.
> 
> Of course AOS 4.0 will be able to run WarpOS software, anything else
> would be quite stupid.

OK time to kill some wasted bandwidth here

Heres an official statement.

"OS4.0 will run existing WarpOS apps"


> As you canan probably tell from the pictures of the board, the AmigaOne
> uses ATX power. However, atm my A1200 is powered by an AT power supply in
> my PowerTower, through a Mediator.
> 
> Will the AmigaOne's power supply be used to power the A1200 mobo in a
> similar fashion to the Mediator and other busboards? My guess is yes, but
> just for comfirmation... :)

Yes (just like all the other PCI cards!)


>> So why are Amiga giving a copy of 4.0 and 4.2 away for free if you
>> buy the SDK1.1? You will just have two copies of 4.0! Surely?
>
> Presumably because you have to pay /extra/ for OS4.0 when you buy an A1; say
> $500 for the hardware plus $100 for the software. (Somebody already made
> the point that two different companies are involved, Eyetech and Amiga.)
> The offer then gives you a saving of $100, either on the OS or on the
> machine, depending which way you look at it.

The A1-1200 will be sold via dealers (including our retail division) who
will all purchase at the same price. Dealers will buy A1 boards from the
manufacturing division.

They can then buy CPU modules and A1200 tower cases from us or elsewhere

They will buy memory, HD's, CD/DVD ROMs etc etc from their regular local
suppliers

They will buy OS 4.x from Amiga Inc or their nominated distributor. This
will be needed unless the A1 is bought as a hi-tech paperweight.

The dealer will then have the option of selling individual boards/cpu
modules/OS4.x, fully configured A1200 tower upgrade kits, fully built
systems, or, from OS4.2 onwards, fully configured systems in a standard ATX
case without an A1200.

We can not add any value - only cost and margin - by selling dealers things
that we do not produce, and this includes OS4.x. Thats why dealers will add
OS4.x into the bundle themselves.

If the voucher is (via dealers) applied to the A1 then we rebate the
dealers. If to OS4.x then AmigaInc's OS4.x distributor rebates the dealers.

AmigaDE / AmigaOne audio - report from Simon Goodwin

On 28-Mar-01, Don Cox wrote:
> Hello Simon
>
> I'm forwarding this from the AmiOpen list. I would think NDAs prevent
> most of the questions from being answered.

Indeed, but they are sensible questions about issues which do concern us, and they can be answered in general, as the chip at the core of our system is public knowledge, and outline specifications for it are available. So it's time to open the kimono, a bit... :-)

Before I start, I should say that this text and the accompanying diagram is a description of work in progress. It's likely that there will be several versions of the product with varying features. This is not an offer for sale, and we reserve the rights to add or remove features from the released product or to change aspects of the implementation. But this will give you a good idea of what we plan.

> *** Forwarded message, originally written by unlyrn on 27-Mar-01 ***
>
> A while ago I asked if we could get a bit more info on the audio
> situation, I don't recall ever getting a reply, Gary? afaik, Simon Goodwin
> (my apologies if that's wrong) is the audio guy there at AI, perhaps he
> could answer a few questions... Firstly, how far along is the audio engine
> in AmigaDE? I don't have access to the SDK, but I'm assuming audio output
> is only in stereo? I'd really love to see multi-channel audio I/O running
> in a hosted environment (eg an AmigaDE software sampler outputting on 8
> channels via a Windows ASIO card), but if this is not going to happen, I'd
> like to know sooner rather than later...

The streaming system in the AmigaDE supports any number of streams and any number of inputs and outputs. The minimum a hosted environment must support is stereo output, but the existing DSFX allows multiple applications to write to that simultaneously.

Of course a pure Amiga system such as AmigaOne must do far better than that! The soundcards we specify support many simultaneous outputs - the exact number depends on the card and not all will necessarily be wired up - you can't get all the sockets on the bracket of a single PCI slot! - but the EMU10K1 DSP chip which is the core of the audio hardware we specify for ANY new system compliant with Amiga low-level audio drivers has the following outputs and inputs:

DIGITAL outputs - four stereo channels

FOUR stereo digital audio outputs configurable to AES/EBU (professional XLR digital audio), S/PDIF (phono domestic digital audio) or TOSlink (optical) standards. These can support AC3 Dolby Digital compressed surround sound, or be used in combination to provide uncompressed true 3D surround sound for more speakers with far more flexible configuration than Dolby or DTS can offer.

DIGITAL inputs - two stereo channels

You don't ask about this, but inputs are just as important to us. There are two digital inputs which support all the above standards and - most crucially - can operate at any standard sample rate, automatically synchronising to the internal rate of the Amiga. So you can feed audio directly from DATs, CDs, DVDs and MiniDisc hardware into our system and mix between them without sync or sample rate problems. Either of these inputs can also handle AC3 Dolby Digital 5:1 format, and route it without data loss to one of the ditial outputs.

Analogue channels: stereo in and one, two or four out!

In addition to these standard digital audio connections the design has provision for standard analogue to digital converters (ADCs) and digital to analogue converters (DACs), which you can plug into amplifiers or other analogue equipment.

The standard for connecting analogue signals to a digital signal processor is I2S, which supports a stereo stream in one direction. We have dedicated connections for I2S input and output to the analogue world. We can also set one of the aforementioned digital outputs to work in I2S to drive a second stereo analogue amplifier. We also have a separate I2S input (with sample rate conversion) for a tuner card or other expansion card internal to the Amiga.

There is another way to get extra outputs without changing the chip at the core of the Amiga audio-subsystem or the software interface to it. Sound cards used to be built with separate stereo ADCs and DACs, and Amiga supports this as it give the best quality. But the first pair of I2S input and output connections previously mentioned can be configured as an AC97 digital interface for an external codec - an all-in-one input and output chip.

AC97 is the de facto standard for 16 bit in and output on a 'PC' (spit) and normally supports a stereo output and separate stereo and mono inputs. However we support the updated 2.1 version of the AC97 spec which allows up to eight DACs embedded in a single chip. Typically AC97 support on a PC motherboard is limited to stereo, but codec manufacturers are now making parts with two, three or four stereo DACs encapsulated.

Thus the upper limit of an Amiga system - with a single DSP - is four stereo digital outputs, AND four stereo analogue outputs (via AC-97) - that's up to sixteen mono outputs all with different data and nine mono inputs (stereo and mono analogue, one I2S internal, and two TOSlink/S/PDIF/AES-EBU) all potentially at different sample rates. All these can be up to 20 bit resolution, depending on the ADC and DAC connected. It makes no difference to the programmer. The streaming software supports 8, 16 and (prefered for mixing and serious work) 32 bit samples. 192 dB should be enough headroom, we hope :-)

So far I've only talked about the DSP which is on the new Amiga PCI bus. In theory you could have more than one of these, but you'd start to run short of bandwidth - there is meant to be some time left over for video, hard drives and other DMA, after all - the whole point is that this is designed as a complete co-operative system rather than a one dimensional PC benchmark engine.

We're not planning to make PCI soundcards - Creative can do a good job of that (well, with help from E-Mu and Ensoniq they certainly can)- though it's possible that we'll get the EMU10K1 and associated interfaces on the motherboard of a future integrated Amiga. For the time being the slot approach means you can pick the number of and type of ports to match your budget.

This is more flexible than the old Amiga approach of having pretty good facilities for all (very good, by 1985 standards, not so impressive now) and means we can develop to a sensible minimum standard without being boxed in (literally or metaphorically) later. We are investigating FireWire and mLan and a load of other systems for high-end audio workstations, for example, but they are not the focus of current work.

The limits of contemporary cards stem not from the DSP or Amiga's software but what the manufacturer has put on the board. Thus you have a choice, from the bottom of the range SoundBlaster 512 or Live1024 - with stereo line in, four analogue outputs and a couple of digital outs on the back panel, and extra digital ins for DVD etc internally - to the SoundBlaster Live Platinum which adds much of the extra capability in a 5.25" drive bay (the Live Drive) with optical and SP/DIF ins and outs and analogue headphone and microphone ports all conveniently on the front of your computer, and out of the way of the noisy motherboard and PCI electronics that would otherwise limit fidelity.

There are half a dozen EMU10K1-based boards available; Amiga is not committed to any one of them in particular - our API talks to the chip on your behalf and makes whatever ports are available visible to the Amiga system. While the EMU10K1 is the core of our current designs, it is not the end of the line for us or the experts at E-mu that designed it. It does most of what we want at the moment, and a lot more than any other PCI sound card solution, but we are fitting an API on top of it so we can upgrade the hardware and everything will still work - just better.

Currently the sample rate limit is 53 KHz but this is just a hardware limitation and our system design does not tie us to this limit in future. We are aware that SuperCD and DVD offer higher rates, though there are unresolved standards and interface issues with those. Assuming we do OK with AmigaOne, we'd aim for rates of at least 96 KHz for audio workstations. AC97 is fixed at 48 KHz, with input conversion hardware so you can record to memory at DAB (32 KHz), CD (44.1 KHz), RealAudio (8KHz) or other rates like 11 and 22 KHz (ish) common on PCs and Macs. We can actually play samples by DMA at any rate up to the limit - much like Paula, but more so. Paula had four eight bit channels hard wired to left or right in stereo. We have 64 equivalent channels, except that we can mix or direct them proportionally to any outputs, and they can be 16 bit not just 8 bits wide, and at higher sample rates. Actually the EMU10K1 is much like an audio Copper - but one capable of implementing hundreds of parametric equalisers or mixer channels, rather than mixed-mode screens and palette stripes!

I hope you can see that this is a system that deserves the name 'new Amiga', and are reassured that we know both what needs to be done and how to do it, now and in future.

> Along the same lines, is any
> extra latency introduced by hosting? In audio work, timing is everything,
> if the hosting layer adds even an extra millisecond, or has 'jitters',
> then its a big problem... anyone working on realtime audio software care
> to comment?

We are well aware of these issues and equally aware that existing computer 'system designers' are not. It is not possible to fix these faults retroactively, but we can and will fix them in our own system - by choosing components that deliver the Quality of Service you and we insist upon, and designing the system as a whole to deliver that potential.

Hosting on a third-party OS is obviously limited by the implementation of that system. If it blocks interrupts or DMA or task-switching, the Amiga layer on top cannot magically cure the problem. It can only add latency, not remove it (the tardis is a long-term research project :-) though it can track it and endeavour to keep it consistent.

You're quite right to assume that this limits performance on Windows, Unix or MacOS, none of which are realtime systems even by old Amiga 500 standards. For that matter, unapproved hardware or drivers can strangle 'modern' systems or PCI buses - this is not uncommon on non-Amiga systems and not something we can fix.

'Anyone working on realtime audio software' will want to use a system where Amiga controls the entire environment. AmigaOne is the first such system, closely coupled to the hardware so it does not have the limitations of hosts that are not designed for our Quality of Service expectations.

> If nothing else, could someone at AI please forward this to Simon or
> whoever else is the appropriate person, I'd really like to hear about the
> audio layer of the DE,
> Thanks,
> David Shipman

This is direct from Simon Goodwin, accept no substitute. :-)

I have responded to this email because it's clear that you understand some of the key issues - we are well aware of those and others that you have not considered yet. Bear in mind that there are just five people in the core Amiga audio team, and they have lots to do. There are some other major Amiga audio developers and experts - such as Don Cox who forwarded this mail - advising the audio group. We're not hiding, but we are focusing on the real job rather than publishing wishlists or development diaries. We are also working closely with hardware partners, and programmers at Tao and Sseyo, but if you pester them about Amiga issues you're only going to piss them - and us - off.

We shall release more information as we are certain of it, but some details will remain proprietary. So if you've not signed an NDA and got an SDK you will miss out. We are aware that the audio in the first SDK release was basic, but Amiga had nothing to do with that - it's just legacy from Tao's embedded systems. The forthcoming SDK 1.1 will add loads of audio and streaming media infrastructure, and Sseyo's extremely powerful generative audio synth (good enough for Brian Eno :-). Amiga will add layers on top of this, to manage streams and control signals and MIDI applications, and these will be available on all hosts. More important from your point of view, we shall add low-level device drivers specifically for the hardware we specify - initially based around the EMU10K1 though not bound solely to that in the way the old Paula drivers were - and those will deliver the realtime response and scalability you call for. E&OE!

Further reading:

Ambisonics:

http://www.york.ac.uk/inst/mustech/3d_audio/ambis2.htm
http://www.stanford.edu/~mleese/Ambisonic/why.html

Explains how to support any number of speakers anywhere in 3D by mastering just four uncompressed streams, W, X, Y and Z.

Some background on the EMU10K1 and its relatives:

ftp://opensource.creative.com/pub/doc/m2049.pdf

ftp://opensource.creative.com/pub/doc/hog63.ps

Note that Amiga has a lot more information than these (or the open source Linux drivers) contain but it is under strict NDA.

AC97 specs (just for interest, not that we're limited to these)

ftp://download.intel.com/ial/scalableplatforms/audio/ac97r21.pdf

Finally, please do NOT email us or our partners with requests for futher information or your advice on strategy or tactics. That will only cause delays. We will tell you more, and more concretely, as soon as we can, but need to concentrate on implementing what I have outlined, so you can play with that and extend it, rather than just dream about it.

Cheers,

Simon N Goodwin
Contractor, Amiga Inc
Team Lead, Audio Development

AmigaOne SCSI standards - report posted by Amiga Inc

Fleecy has also asked me to recommend a PCI SCSI card or chipset on which to standardise, and I'm fairly sure I know the right ones to pick. I've been a SCSI enthusiast since 1987, and written drivers for (very) dumb and smart controllers. I do understand the options and the issues, as I'll show. We should standardise on an 'NCR SCSI scripts' processor, for the following reasons.

These are low-cost high-performance single-chip PCI bus-mastering SCSI controllers. They are widely available in SCSI 2 FAST and Ultra/SCSI-3 versions, originally from NCR then Symbios, now a brand of LSI logic, http://www.lsilogic.com. There is a good OEM support program there - another reason for chosing this rather than an Adaptec proprietary part, for example - and they encourage people to buy either boards with chips on (e.g. from lots of firms in China, Korea and Taiwan) OR the chips themselves for integration (as on Commodore's A4000T) so programming and electronic specs are both good and easy to get. Hence they are widely supported with free and compatible drivers, and as close to a commodity as controller chips get.

You can buy PCI cards in this architecture from ASUS, Diamond Multimedia, DTC, Intraserver, Lomas Data, SW Technology, Topsys and Tyan, among others. Each offer versions that match several variants of the SCSI standard - unsurprisingly, as the software drivers and PCI connector stay almost the same, and only the integrated controller/interface chip and SCSI sockets need to change (basically).

There are lots of chips in the 'SCSI scripts' family and they all have a similar programming interface, which I'm very familiar and happy with as both a user and a programmer.

Chips in this family include the 53C710 used in the Warp Engine, CSA Magnum and A4091 (Zorro 3 cards and accelerators - I've written drivers down to the metal for these, in Amiga Qdos) which are SCSI 2 FAST. These were the fastest, lowest-overhead SCSI 2 controllers for Amigas, and in my experience very tolerant of cable and termination mistakes that clobber rivals. This feature is trademarked as 'TolerANT' and involves the controller monitoring the bounce on the I/O lines and tuning the line drivers accordingly. It works. :-)

The Cyberstorm 3 and Cyberstorm PPC were based on a Symbios clone of the NCR53C770 Ultra SCSI script processor. Phase 5 abandoned the Elonex FAS216 they had inherited from the Fastlane Z3 cards and used in Mark 1 and 2 Cyberstorms, and so the Mark 3 was faster and more reliable, with lower CPU overhead than earlier models, even on 'narrow' SCSI drives.

The main snag of the Mark 3 SCSI was that it only shipped with wide (68 pin) connections and required expensive connectors and cables to work with cheap and common SCSI 2 gear. It's important that we should offer a choice of SCSI 2 FAST and 'Ultra Wide SCSI 3' (pick your labels :-) controllers so people can use their existing equipment (scanners, DATs, ZIPs as well as intelligent fixed drives) with low cost, and those who have or want later 'wide' gear can use it, without us having to write new drivers.

The most basic PCI version of this is the 53C810, which I use (in the SymBios remix) in my Devbox. The chip has the same advantages but even higher integration as it drops onto PCI rather than the CPU bus or - via glue - to Zorro 3. However SCSI 2 FAST is a minimum, these days; raw IDE can outrun it, though not if you have several drives active at a time. There are ultra wide and differential versions of the PCI chips, too.

These are some of them - there are probably others:

• 53C810A: Fast SCSI-2 (10 Mb/s)
• 53C815: Fast SCSI-2
• 53C825: Fast Wide SCSI-2 (20 Mb/s)
• 53C860: Fast-20 SCSI
• 53C875: Fast-20 Wide SCSI (40 Mb/s)
• 53C895: Ultra2 LVD (80 Mb/s)
• 53C896: Ultra160 (160 Mb/s, two channels)

The part numbers might have NCR, SYM or LSI prefixes. The 5 suffix indicates support for a BIOS ROM - which can be serial or flash, programmable in situ - this is mainly to help ignorant PCs boot from SCSI. It's not clear if this will be needed for AmigaOne - probably not if there's room for a bootstrap loader in the ROM that configures PCI, but if not we should be able to put our own code in without much trouble.

Do not confuse these with the old 5380 chips used in old Macs (and Emplant). These were very limited in speed and required host interventions for every SCSI phase change. The 53C90 (in Mac 2s) could get by with about half as much driver code as it had hardware arbitration for common SCSI bus state changes, but it was still a 'dumb' chip reliant on interrupting the host whenever a decision needed to be made.

Drivers for all the smart chips are very similar, and a lot shorter and simpler than the drivers for rival SCSI controllers, thanks to a (very) RISC 'SCSI scripts' processor which takes all the load of SCSI bus phase control off the main system, and the programmer of the driver :-)

The SCSI scripts program and state machine works out whether we are handling commands or data, resolves contention and hard and soft errors, allowing drives to disconnect and reconnect so they don't clog the bus while they perform internal operations, etc... The result is a driver that looks simple but handles all complicated cases implicitly, and takes multi-threading in its stride.

SCSI scripts are made of 64 or 96 bit RISC instructions read from the host memory by DMA or from internal memory on later chips in the series. We don't need to write a SCSI script program, though it may be useful - NCR's standard ones cope with all the SCSI phases and types of transfer, and most implementations just use them and wrap host code around it to trap completion interrupts and set it off again.

The 53C7xx and 53C8xx parts have a relatively tiny host overhead - between one and five per cent of that for a second-generation 53C90 - because once you've told it what to do the controller goes ahead and does it, coping with disconnection and reconnection so other devices can share the bus and the host doesn't have to wait for seeks - a major advantage of SCSI over IDE - and scatter/ gather operations for blocks fragmented through memory, which will be significant in implementing virtual memory. Anyhow, arbitrarily-sized blocks of data are moved to or from host memory by PCI DMA and the only interrupt is at the end when the job - or a sequence of transfers - is done, or if an error occurs in the meantime.

You don't have to use DMA or SCSI scripts, though it is most efficient - for test purposes you can treat the controller as an entirely dumb one and peek and poke a byte at a time, which may be useful for a minimal bootstrap or support for sub-standard peripherals.

It can do more than just read and write the SCSI bus - as it has bidirectional DMA you can use it as a general-purpose block transfer device to take the load off the CPU when moving data around main memory or between motherboard RAM and video RAM, let's say. It can even do horizontal and vertical scrolling and window operations, though you'd probably want do this using the video card local CPU and bus in practice :-) The memory move instruction is stunningly simple, and a good example of SCSI scripts. It's 96 bits long. The first byte is 192 (top two bits set - these sift between four basic RISC instruction groups). The rest of the first (long) word is a 24 bit count of bytes to be moved. The next two words are the 32 bit source and destination addresses. The main limitation is that those must have the same byte alignment, as the chip does 32 bit transfers, and tries to collect them in line bursts if appropriate.

We don't strictly need this, but if we were to make our driver offer this functionality to applications (with a hardware abstraction using the host processor or anything else appropriate if the SCSI copro is not present) we would be making better use of PCI and our choice of hardware than any other non-embedded system.

Likewise our SCSI device should support the whole SCSI spec - not just transfers between SCSI devices and memory, but between hosts sharing a bus - no problem as long as they have different SCSI IDs - we should eschew cards that fix the ID at 7 as it's an avoidable limitation - and then they can all share CD ROMs and other peripherals - even writable drives with careful (software) arbitration. And yes, I *know* this works, even on the old Amiga - I've seen Linux and AmigaOS sharing drives on a SCSI chain this way, and there's a SCSI networking example on Aminet that uses SCSI direct commands to make a fast parallel heterogenous drive and computer cluster. There are other ways to do this - Firewire, Ethernet, even USB at a pinch - and I don't suggest that we should put effort into implementing it ourselves - but we should specify hardware and drivers that do not prevent it if we or third parties see value in the concept, later.

Software issues

The whole thing should be wrapped in whatever scheme we use for DMA device drivers, so we're not committed to the NCR family if something else comes along and we write fresh drivers for it. We have to support synchronous and async I/O, and SCSI-direct (which is the Classic Amiga scheme to allow any command to be sent directly to any device in a host-independent way). The existing API is fine, and hence any superset of it would be, except that the late addition of QuickIO - where a device call may take place in the caller's context, without contextr switching to another handler or device driver task, and does not return till complete - needs to be made a core, guaranteed part of the spec. QuickIO could have been very useful to address complaints about the OS getting in the way of dedicated high performance systems like multi-tracking, but wasn't useful in old Amiga products since not all handlers and device drivers implemented it and Commodore defined it as an option, not a requirement (so it was widely ignored). This was a good idea which we should follow through.

SCSI-direct allows custom support for new standard extensions, non-standard or broken devices (like the NEC drives that interpret binary parameters as BCD! 8-) by passing arbitrary SCSI commands to a device, and marsalling the results, in a way that does not obstruct standard uses or sharing of the SCSI bus.

SCSI-direct allows specialist applications to use some of the SCSI features that are not available on IDE or other types of drive. For instance a SCSI drive can be programmed to search itself (with fields to skip and check) and call any other device back when it has found certain data. This requires a command with no equivalent for other types of devices, which would have to read all the data over the bus and check it with the main CPU. We could add this function to our API and do it the hard way for non-SCSI devices and cleverly for SCSI ones, but there is no need to make this a standard interface - as long as SCSI direct is available, programs for dedicated database or streaming applications can access the functionality without making life more complicated for conventional applications.

It would probably be worth adding this, especially if SCSI takes off on Amiga or other drives (e.g. over ATAPI or firewire) offer equivalent functions, but this should not be a priority. For the time being SCSI-direct meets the requirement for those that understand and need it. As it is a low-level path into code that already exists to implement more abstract I/O operations, the cost of making it available is tiny, and we can build on it ourselves, for instance to extend third-party drivers in an Amiga-general way.

Another neat trick possible with SCSI-direct, as long as you know the topology of your system in a bit more detail than device-independence allows, is to program a drive to copy or mirror itself to another. This can be done without host intervention (other than reselection when it is done) as all SCSI devices - not just the host - can master the SCSI bus and transfers can be between any two devices, without blocking processes of other transfers, subject to well-defined and efficient priority and bus sharing protocols.

Horray for SCSI! Horray for SCSI scripts processors!